As web service applications have become more complex, the first generation web service architecture no longer adequately accommodates development requirements for current web services. Thus, a Service-Oriented Architecture (SOA) has been proposed. SOA establishes the concept that a web service system may be composed of a series of sub-systems or services that are separate but that cooperate with each other. Such a structure enables the services to be separated. Each service needs only inform other services of its declared interface. Therefore, SOA allows corporation business flows to be created that are only loosely coupled. Where SOA concepts are used, a web service system may be formed by web services executed in remote and different domains, replacing the conventional hierarchical structure of a system with service flows across various business areas.
In order to satisfy a user's requirements for quality of service, a SOA system may be required to comply with a Service Level Agreement (SLA) that defines the level of service expected by the user. Web service policies are used to describe the requirements and abilities of a web service in its interactions with other web services or consumers and are important in setting up Service Level Agreements.
The term policy relates to non-functional, characteristics, such as a variety of fields of security, reliability, transaction, privacy, and so on, corresponding to the functional elements in an SOA system. Similarly, a way to express policies is not limited to the expression of common policies or security policies. A web service policy generally includes a Policy Framework (WS-Policy) document that defines the syntax for expressing the policies of a web service; a Policy Attachment (WS-Policy Attachment) document that defines how to attach these policies to a web service; a General Policy Assertions (WS-Policy Assertions) and a set of Security Policy Assertions (WS-Security Policy).
The Web Services Policy Framework (WS-Policy) defined by IBM, BEA, Microsoft and others is the de facto standard for Web Services policy. It provides a common model and corresponding syntax to describe policies of a web service. WS-Policy is intended to allow for extensibility. That is to say, WS-Policy defines a base set of constructs that can be used and extended by other web services specifications to describe a broad range of service requirements and capabilities (the non-functional part). Based on WS-Policy, a set of standards have been defined for different perspectives of a system, including Web Service Reliability Messaging Policy (WS-RM Policy), Web Service Security Policy (WS-Security Policy), Web Service Atomic Transaction (WS-Atomic Transaction), Web Service Policy Assertions (WS-Policy Assertions), etc. Users can also define policy languages based on WS-Policy and related standards for their needs.
Currently, most of the attention of system developers is focused on runtime policy enforcement. However, design-time policy enforcement and validation is important to validate the conformance of services before they are put into production. For example, one currently available Policy Manager provides a tool for validating compliance to a WS-I (Web Services Interoperability) Organization basic summary containing implementation principles for kernelled web service specifications, which are a set of requirements defining how to apply these specifications to develop co-operable web services, documents integrity, syntactic validity of single service. However, this tool concentrates on the validation of correctness, integrity and validity of policies for a single service.
There is no known method and tool for validating correctness and consistency of service policies at the design time of a SOA system, nor is there any known tool for generating framework of non-functional infrastructure for the SOA system.